REMARKS 

Claims 1-12 and 19-25 are currently pending in the application. In the Office Action 
mailed March 21, 2008, claims 19 and 22 stand rejected because of alleged informalities. 
Claims 1-12 and 19-25 stand rejected under 35 U.S.C. § 103(a) as being allegedly unpatentable 
over Justice, Jr. et al. (US Patent No. 6,418,469) in view of Roytman et al. (US Patent No. 
6,356,282) and further in view of Johnson (US Patent No. 6,275,855). 

Applicants respectively traverse. After a careful review of the Office Action, the cited 
references, and Applicants' claim clarifications, Applicants respectively request reconsideration 
in view of the following remarks. 

I. CLAIM OBJECTIONS 

Claims 19 and 22 are rejected to because of informalities. Applicants have revised 
claims 19 and 22 and therefore respectively request that these objections be withdrawn. 

II. CLAIM REJECTIONS UNDER 35 U.S.C. $ 103(a) 

Claims 1-12 and 19-25 are rejected under 35 U.S.C. § 103(a) as being allegedly 
unpatentable over Justice, Jr. et al. (US Patent No. 6,418,469) ("Justice 469") in view of 
Roytman et al. (US Patent No. 6,356,282) ("Roytman 282") and further in view of Johnson (US 
Patent No. 6,275,855) ("Johnson 855"). 

A. Applicants' Presently Claimed Invention 

Applicants' presently claimed invention is generally directed to an apparatus and method 
for management of a network and more particularly to a network management apparatus and 
method capable of generating events when predefined significant conditions are detected. See, 
e.g., Applicants' Specification at p. 1 lines 6-9. 

More specifically, Applicants presently claimed invention is generally directed to 
methods and system that processes received network management data, and determines if the 



network management data indicates that a previous {i.e., historical) event in an event log has 
been resolved and then changing a severity indicator of the previous event dependent on a 
determining step. 

As Applicants explain, when processing of data by the network management application 
detects certain predetermined conditions, the network management application will generate an 
event. For example, if a network device fails to respond to an IP Ping sent by the network 
management application within a predetermined time period, an event will be generated. Such 
events are stored in memory and placed in an event list for presentation, e.g., by display on a 
display screen or by printing in a report. For each event, the information recorded (i.e., event 
data) includes the time of the event (typically by means of a "time stamp"), the identity of the 
device concerned, the type or nature of the event, and the severity of the event. The severity of 
the event is dependent on the type of event and the type of device concerned, and is included to 
assist the administrator in determining which events indicate problems which require the most 
urgent attention. Therefore, events such as an end station not responding to IP Ping has a 
"Low" severity, whereas a similar event for a core device has a "High" severity. 



The following Table is an example of an event list which may be produced for the 
Applicants' network 1 illustrated in Figure 1: 



Time 


Device Name 


Description 


Severity 


11.01 


HUB10-1-72 


Utilization on port 2 
exceeded 80% 


HIGH 


11.03 


S1 000-1 -72 


Errors on port 1 
exceeded 5% 


HIGH 


11.06 


HUB10-1-72 


Utilization on port 2 
exceeded 80% 


HIGH 


11.00 


S1 000-1 -72 


Errors on port 24 
exceeded 5% 


HIGH 


10.58 


S1 000-1 -72 


Errors on port 2 
exceeded 5%. 


HIGH 



10.58 


PSH40-1-72 


Broadcasts on port 12 
exceeded 200% 


HIGH 


10.57 


HUB10-1-72 


Utilization on port 2 
exceeded 80% 


HIGH 


10.56 


S1 000-1 -72 


Utilization on port 24 
exceeded 80% 


HIGH 



Applicant's Table provided above indicates a large number of events having a High 
severity, received over a time period of 5 minutes. Therefore, for a longer period of time, which 
would be more typical of the time interval between reviews of the event list, the network 
administrator will have difficulty in determining which events in the event list indicate current 
network problems requiring attention. See, e.g., Applicants' Specification Page 8 Line 5 - Page 
9 Line 5). 

Applicants' presently pending claims have been clarified to expressly recite such an 
event list comprising a severity indication where the severity indicator is dependent on event 
type and device type. For example, independent claim 1 now expressly recites the step of 
"maintaining an event list, said event list comprising a severity indicator of said previous event, 
said severity indicator dependent on a event type and a device type ." The remaining pending 
independent claims, claims 8, 23, and 24, recite similar limitations. 

A. The Cited References Do Not Disclose Applicants' Presently Claimed Invention 

i. The Presently Pending Office Action Concedes 

That Justice Fails to Disclose "A Severity Indicator" 

Neither Justice nor Roytman disclose Applicants' presently claimed invention. More 
specifically, neither Justice nor Roytman disclose Applicants' presently claimed step of 
"maintaining an event list, said event list comprising a severity indicator of said previous event. 
said severity indicator dependent on a event type and a device type ." As noted above, the 
Office Action rejected claims 1-26 under 35 U.S.C. § 103(a) as being obvious over the 



combination of three references: Justice and Roytman and Johnson. In order to establish a 
prima facie case of obviousness of a claimed invention by applying a combination of references, 
the cited references must teach or suggest all of the claim limitations. M.P.E.P. § 2143. 
Applicants respectfully submit that these rejections are improper, since the present Office Action 
concedes that Justice fails to teach or suggest all of the elements of any of Applicants' presently 
pending claims. Roytman does not make up the deficiencies. Therefore, the Office Action fails 
to establish a prima facie case of obviousness. 

For example, the presently pending Office Action concedes that Justice fails to teach or 
such Applicants' claimed step of "maintaining an event list, said event list comprising a severity 
indicator of said previous event." The Office Action states: 

Justice does not explicitly disclose maintaining an event list, said event 
list comprising severity indicator of said previous event; determining said 
resolution of event in real-time and changing a severity indicator of said previous 
event dependent on said determining step; depending on said severity indicator. 

The concept of having an event list and the event list comprising a 
severity indicator is a well known concept. For instant, Roy [sic] teaches an 
event list and the event list comprising a severity indicator (see Roy figure. 6 and 
figure.7, event list comprising severity indicator). 

It would have been obvious to one with ordinary skill in the art at the time 
the invention was made to combine the teaching of Roy to the method of Justice 
to include the event list and the severity indicator because it would be helpful to 
the network management personnel in identifying and acknowledging the 
network condition (see Roy co1.3, lines 31-43). 

March 21, 2008 Office Action at page 3-4. 

Applicants agree with the previous Office Action that Justice fails to teach or suggest the 
step of "maintaining an event list, said event list comprising a severity indicator of said previous 
event." However, Applicants respectively disagree that Roytman makes up for the deficiencies 
of Justice and therefore respectively traverse this aspect of the presently pending Final Office 
Action. However, in an effort to expedite the allowance of this pending application (an 
application that has been pending in the PTO for well over seven years), Applicants have further 



clarified the pending independent claims to expressly recite the step of "maintaining an event 
list, said event list comprising a severity indicator of said previous event, said severity indicator 
dependent on a event type and a device type ." Roytman fails to teach or suggest such a step. 

Rather, Roytman appears to be generally directed to network management tools 
for managing distributed networks and, in particular, to alarm servicing tools. (Roytman 
Col. 1 Lines 6 -8). 

The present Office Action refers to Figure 6 and 7 of Roytman as teaching Applicants' 
"severity indicator." Applicants' respectively traverse. 

Roytman's FIG. 6 is a screen display of the alarm manager illustrating an alarm 
summary display and FIG. 7 is a screen display of the alarm manager illustrating display of 
individual alarms. Roytman discusses Figure 6 at Col. 8 lines 1 1 - 44 and this discussion is 
provided below: 

In the association viewing mode, such as that illustrated in FIG. 6, an alarm listed 
in the table of alarms actually represents a group of similar alarms. The alarm 
selected to represent the group is either the highest severity, or the most recent. 
The operator can determine the criteria used to select the representative alarm 
when he specifies the association rules. Any action taken on an alarm while 
viewing associations applies to all the alarms in the group associated with that 
alarm. For example, if an alarm is acknowledged in the association viewing 
mode, all alarms in the same association are changed to an acknowledged state. 

The alarms can also be filtered to select only those that match selected criteria. 
The criteria include managed object instance or the device triggering the alarm; 
managed object class or the type of device or resource generating alarms; alarm 
state or severity and event type, such as communications, Internet, etc. Further 
filtering can be performed on the date and time, acknowledgment operator or the 
user name of the operator who acknowledged an alarm, acknowledgment date, 
clear operator or the user name of the operator who cleared an alarm, clear date 
and problem code or the numeric or textual ID of the probable cause of an alarm. 



As can be seen from this discussion, Figure 6 of Roytman simply does not teach or 
suggest Applicants "maintaining an event list, said event list comprising a severity indicator of 
said previous event , said severity indicator dependent on a event type and a device type ." 




Figure 7 of Roytman fails for similar reasons. For example, Roytman discusses Figure 7 
at Col. 8 line 46 - Col. 9 line 14 and is provided below: 

One problem with the alarm instances window illustrated in FIG. 7 is the 
scroll bar 704 which allows an operator to scroll particular lines representing 
individual alarms onto the display screen. When the alarm log has many 
records, the large number of rows will not fit on the screen display 700. 
Consequently, the scroll bar 704 is provided to allow a user to scroll the records 
up and down on the screen so that a desired record can be brought into view. 
When new records are added to the display, the scroll bar thumb 706 typically 
flickers and resizes to alter the user that new records have arrived. 

However, the flickering and resizing of the scroll bar thumb 706 is not 
sufficiently noticeable to signal network management personnel that new events 
have arrived. Even if an operator is viewing the display when new events arrive, 
it is very easy to the resizing and thus very critical events. In addition, if an 
operator actually wants to see all of the incoming events as they arrive, the 
operator must continually click on the scroll bar 704 as events come in. In a busy 
system, it is impossible to click fast enough to see all events. Further, it is difficult 
to accurately move the scroll bar thumb 706. An operator can click on the scroll 
bar arrow buttons 702,708 to scroll the events, but the arrows 702,708 only 
scroll down the display one event at a time and thus are slow to use. It would be 
more advantageous to click on the slider 710 between the scroll bar thumb 706 
and the arrow 708, but if the log is large enough, this area is so small that it is 
nearly impossible to keep clicking in it accurately. In addition, depending on a 
sort order, newly arrived alarms 902 can arrive at the top or bottom of the alarm 
list. In accordance with the principles of the present invention, a scrolling 
function is inserted between the incoming alarm records and the tabular display, 
such as display view window 700. In addition a user interface is added to control 
the scrolling. The scrolling direction can be either "up" or "down", depending on 
the alarm sort order so user will always see the latest incoming alarm. 

As can be seen from this discussion, Figure 7 of Roytman simply does not teach or 

suggest Applicants "maintaining an event list, said event list comprising a severity indicator of 

said previous event , said severity indicator dependent on a event type and a device type ." 

Consequently, since Roytman fails to teach or suggest the step of "maintaining an event 
list, said event list comprising a severity indicator of said previous event , said severity indicator 
dependent on a event type ," Roytman naturally fails to teach or suggest the step of "maintaining 
an event list, said event list comprising a severity indicator of said previous event , said severity 
indicator dependent on a event type and a device type ." Justice in combination with Roytman, 



therefore, fails establish a prima facie case of obviousness. 



III. SUMMARY 

Applicants respectfully submit that, in view of the remarks above, the present 
application, including claims 1-12 and 19-25, is in condition for allowance and solicit action to 
that end. 

If there are any matters that may be resolved or clarified through a telephone interview, 
the Examiner is respectfully requested to contact Applicants' undersigned representative at 
(312)913-0001. 

Respectfully submitted, 

McDonnell Boehnen Hulbert & Berghoff LLP 



Date: September 22, 2008 By: /Thomas E. Wettermann/ 

Thomas E. Wettermann 
Reg. No. 41,523 



